A probe theme covering every theming target, and a PR-scoped visual job - #5396

…sual job

Two gaps the release gate left open.

THE PROBE THEME. Real themes style what their designer cared about, so most of
the themeable surface was never exercised by any of them — and a newly added
target starts life in that unverified set by default. Nothing notices when it
stops working, because nothing was styling it.

packages/themes/probe is GENERATED from the same target enumeration the CLI
uses, so a target added tomorrow is covered the moment its doc lands: 248
targets, 795 selectors, against 25 keys across all seven real themes. Each
selector gets a distinct hashed colour, and text/background/border differ, so
two sub-targets that collapse onto one element show as one colour instead of
two — which a uniform hot-pink theme would hide. Private, never published, and
visual:probe-theme:check fails CI when a target is added without covering it.

Effect on the gate: declared targets no shot could verify drop 52 -> 8. The
remaining 8, and the 49 unexercised real-theme overrides, share one root cause
— no story renders them at all.

THE PR-SCOPED JOB. pr-visual shoots every story of a touched component in every
theme that styles it (deeper than the daily gate, which shoots one
representative story), scoped by the same analysis.json pr-a11y uses: a median
PR is ~16 shots, ~10s. Over 240 shots it declines and says why — a token change
would put hundreds of diffs in front of a reviewer who cannot judge them one by
one, and the daily gate reviews that against the whole baseline instead.
Non-blocking while it earns trust.

A scoped run no longer reports the rest of the baseline as removed, and shots
the daily baseline does not reach are reported as unbaselined rather than as
additions — both would otherwise appear on every PR.

…lds it

    <Package>/<Component>/(Default | Theme Sheet | …)
    <Package>/Hooks/<hook>
    <Package>/Themes/<theme feature>

A reader could not guess where anything lived: six hooks sat beside components
under three different parents, five theme-level features were filed as if they
were components, and one story was under a 'Components' category that exists
nowhere else. Nothing but a reader could notice, which is why it drifted.

The test reads the BUILT index, so it judges what Storybook renders rather than
what the source appears to say. Charts/Chrome/* and Lab/3DChart/* stay as
deliberate sub-grouping.

Titles only — no story moved file, no render changed.

The README now carries the pattern, including the part that is easy to get
backwards: a Theme Sheet must NOT wrap itself in <Theme theme={…}>. Several
existing 'Themed*' stories do, which overrides the global theme, so the toolbar
cannot switch them and the visual gate can never probe them — they are
invisible to exactly the testing they look like they are helping with.

The reach check existed but nothing ran it, so the 50 standing misses would
have quietly come back. It is now a leg of the release gate, reported in the
job summary with its own artifact.

Reported, not enforced. Every one of today's misses traces to a single cause —
StyleX emits into @layer priority1-4, which sort AFTER astryx-theme, so
wherever a component sets a property the theme override loses. Failing the gate
on a known systemic issue teaches everyone to ignore the gate. Enforce it when
that is fixed and the count is zero.